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MEDICAL FACILITY COMMUNICATIONS 
TOPOLOGY 

FIELD OF THE INVENTION 

The present invention relates generally to information infrastructures for 
hospitals, clinics, and other medical institutions. More particularly, the invention 
relates to a technique for exchanging information within a medical facility via an 
improved topology linking various equipment and networks into a data exchange 
infrastructure. 

BACKGROUND OF THE INVENTION 

Medical institutions and facilities offer an increasingly wide range of 
services and procedures to meet the needs of their patients and staff. Hospitals, 
clinics, and other medical institutions may include simple single-office clinics, or 
large integrated establishments comprised of a wide array of cooperating 
departments and facilities. Moreover, even smaller clinics may be partially or 
fully integrated into a larger institution at a single location, or geographically 
disbursed from one another. In all of these cases, information technology is 
becoming a key component in the exchange of data and services needed to carry 
out the mission of the facilities. 

In a typical clinic or hospital, for example, a radiology department may 
dispose of various types of imaging systems, including magnetic resonance 
imaging (MRI) systems, computer tomography (CT) systems, ultrasound systems, 
x-ray systems, and so forth. Certain of these systems may be stationary, while 
others may be moved around the facility as needed. A radiology department 
informational system (RIS) may be interconnected with these various imaging 
systems to coordinate their operation, as well as to facilitate their review of images 
by radiologists and diagnosing physicians. In certain institutions, these various 
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pieces of equipment may be interconnected in a network, typically in a local area 
network (LAN) architecture. 

In addition to radiology equipment, various other equipment within a 
5 medical facility may be monitored or networked at a departmental or institutional 

level. Patient monitors, for example, may offer some degree of networking 
capability, allowing patients to be tracked and their physiological condition to be 
monitored remotely. Patient records, accounting records, and the like may 
similarly be associated in different individual systems, with certain of the 
10 information being cross-referenced in a hospital information system (HIS). 

While certain of the equipment within a hospital or other medical 
institution can be designed to function completely independently of other 
equipment or service providers, many individual systems or subsystems are now 

15 designed to interactively communicate information with outside components. For 

example, in the diagnostic imaging field, individual systems are now commonly 
equipped with a modem by which they may transmit and receive image data, 
service information, reports, and so forth. In certain instances, operations 
personnel may log on to a network, such as the internet, or a virtual private 

20 network, to transmit and receive data directly from the imaging system. Other 

equipment within an institution may be similarly equipped for data 
communication, either individually or via a departmental work station or similar 
interface. 

25 While individual networks within a medical facility may function 

adequately for most purposes, they pose certain problems on the level of 
coordination and delivery of data, and may strain the infrastructure of the 
institution. Depending upon the type of connections provided, for example, 
medical diagnostic imaging systems may each require a separate communications 

30 line to insure connectivity when needed. In a typical setting, these communication 

lines are conventional telephony cables which must be installed and maintained 
for the individual systems, even when the systems are not logged on to a network 
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or transmitting data. When data is transmitted to or from individual pieces of 
equipment or individual LAN's of an institution, separate accounting may be 
required, and interface components must separately route the data to and from 
each system or piece of equipment connected to a LAN. Again, this procedure 
5 may require separate connection procedures via dedicated lines, adding not only to 

the overall cost of the system and infrastructure, but adding substantial time and 
additional steps to the data interchange process. 



While some progress has been made toward linking individual networks and 
10 systems of medical institutions, further improvements are needed. There is a 

particular need, at present, for a technique which would permit and coordinate the 
exchange of data among internal systems and networks of a medical facility, and 
with external resources, such as service providers. The need extends both to 
relatively small institutions or clinics, which may have a few pieces of medical 
15 diagnostic imaging equipment, to large integrated institutions in which entire 

departments may be served by outside resources and communicate with those 
resources completely independently from one another under present schemes. 



SUMMARY OF THE INVENTION 

20 The present invention provides an improved data communications topology 

for a medical institution designed to respond to these needs. The technique of the 
invention offers rapid and effective data exchange within the institution, and 
facilitates transmission of data to a remote service provider, and routing of data from 
such a service provider to designated diagnostic systems of the institution. The 

25 technique may be equally well applied to existing facilities having partial or fully 

networked environments, and to institutions upgraded to offer such networking 
capabilities. 



In accordance with the technique, a plurality of client diagnostic systems are 
30 connected to an internal network of the institution. A data communications control 

system permits data from the systems to be accessed via the internal network. The 
data may include service requests, requests for programs and software, requests for 
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documentation and training materials, and so forth. The data is then transmitted to a 
remote service provider as needed, through a reduced number of connections and 
data transmission sessions. Data from the remote service provider is received by the 
control system and is distributed to designated diagnostic systems as desired. The 
technique offers enhanced connectivity, facilitates data access and transfer, and 
provides for improved interconnectivity of devices and systems of the institution. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagrammatical overview of a data communications system for 
communicating data from a series of medical diagnostic systems to a remote 
service or data provider; 

Fig. 2 is a diagrammatical view of an exemplary data communications 
control system in accordance with certain aspects of the present technique for use 
in the system shown in Fig. 1 ; 

Fig. 3 is a data flow diagram illustrating the paths that data takes in the 
communications through the various components of the system of Fig. 1; 

Fig. 4 is a flow chart illustrating exemplary control logic in initiating a 
service request or other data transfer between a medical diagnostic system and a 
remote service provider; 

Fig. 5 is a flow chart illustrating exemplary control logic in handling 
service or data requests by a remote service provider, and for retransmitting data 
in response to such a request; 

Fig. 6 is a flow chart illustrating exemplary control logic for receiving a 
transmission from a remote service provider at the medical diagnostic facility; 

Fig. 7 is a flow chart illustrating exemplary control logic for receiving data 
via an alternative data communications medium; 

Fig. 8 is a flow chart illustrating exemplary control logic in polling or 
sweeping systems of a medical diagnostic facility or data for retransmission to a 
remote service provider; and 



15-SV-5373 



Fig. 9 is a flow chart illustrating exemplary control logic for accessing the 
data collected in the process of Fig. 8 for handling and storage by a remote service 
provider, 

DETAILED DESCRIPTION OF THE INVENTION 

Turning now to the drawings, and referring first to Fig. 1, a data 
communications system, designated generally by the reference numeral 10, is 
illustrated for transmitting operational data or parameters from a series of medical 
diagnostic systems to a remote service or data provider. The system also permits 
interactive exchanges of data, service requests, software, and so forth between the 
systems and the remote service provider as described more fully below. As 
illustrated in Fig. 1, system 10 generally includes a medical diagnostic facility 12 
which is linked to a remote service or data provider 14. The facility 12 may include 
a single location or site 16, or additional cites 18, which may be geographically local 
to or remote from site 16. In such cases, the additional sites may generally be 
interconnected with site 16 via a facility network. 

Within facility 12, an internal network 20 provides a mechanism for data 
communications between a series of medical diagnostic systems, which where 
desired may be provided in groups or departments 22, such as floors, wards, 
specialized treatment or diagnostic areas, and so forth. A series of medical 
diagnostic systems, referred to herein generally as clients 24, are coupled to network 
20 either through permanent network connections, or through temporary network 
connections. Thus, while some or most of the clients 24 may be stationary, certain 
of the clients may be mobile, allowing the client or asset to be utilized in a desired 
location, and to be coupled to the internal network once positioned at the desired 
location. 

As used herein, the term medical diagnostic system should be understood to 
include a wide variety of equipment, systems and subsystems. By way of example, 
medical diagnostic systems may include diagnostic imaging systems designed to 



15-SV-5373 



produce useful images of patient anatomies in accordance with particular physics or 
modalities. Other medical diagnostic systems may include patient monitors, 
sensors, transducers, and other signal-generating or feedback devices. Moreover, the 
medical diagnostic systems communicating in accordance with the present technique 
5 may include information management systems, workstations, image and data 

viewing stations, and so forth. 

By way of example, in Fig. 1, a series of medical diagnostic imaging 
systems are illustrated in one group. In practice, this group may be physically or 

10 logically associated with a radiology department or clinic. In the embodiment 

illustrated in Fig. 1, these systems include a magnetic resonance imaging (MRI) 
system 26, a computed tomography (CT) system 28, an x-ray system 30, and an 
ultrasound system 32. These systems all preferably comprise client diagnostic 
systems for the present technique. As will be appreciated by those skilled in the art, 

15 each of these imaging systems is configured to produce useful image data based 

upon particular physics of their respective modality. As noted above, certain of 
these systems may be mobile, such as ultrasound systems which may be relocated to 
a desired room or examination area and connected to network 20 at that area or upon 
return to a base station. 

20 

By way of further example, in the embodiment illustrated in Fig. 1, the client 
diagnostic systems also include a series of data management stations. As indicated 
by reference numeral 34, then, the clients may include a radiology department 
informational system (RIS) designed to manage the production and flow of image 

25 data in conjunction with imaging systems 26, 28, 30 and 32. A hospital information 

system (HIS) 36 provides additional data, patient, financial, and other support for the 
operation of facility 12 in accordance with generally known techniques. Finally, a 
picture archiving and communication system (PACS) 38 provides for storage, 
processing, access and archiving of data files produced by the diagnostic imaging 

30 systems. 
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Each of the client diagnostic systems is coupled to network 20 for 
exchanging data with a remote service or data provider as described below. In 
heretofore known data exchange techniques, certain of the client systems may be 
equipped for independent exchange of operational or parameter data as required for 
5 servicing, maintenance, analysis, accounting and similar needs. In accordance with 

such techniques, an independent connection could be established between the assets 
and a remote service provider, such as via an independent modem connection as 
illustrated for ultrasound system 32 in Fig. 1. In accordance with the present 
technique, although certain of the systems may continue to permit such direct 
10 connection, the client diagnostic systems need not be capable of such separate 

connectivity. Rather, data may be exchanged between the systems and a remote 
service or data provider via network 20. 

In the presently preferred embodiment, network 20 comprises a high-speed 
1 5 internal network, such as an Ethernet network. In current embodiments, the network 

may be a 10Mb or a 100Mb network exchanging data in accordance with a standard 
data exchange protocol, such as TCP/IP. Of course, other internal network 
architecture and standards may be employed. 

20 The communications system further includes a data communications control 

system (DCCS) 40 which is coupled to network 20 for receiving or accessing data 
from the client, and for exchanging data with one or more remote service or data 
providers. The DCCS 40 is thus coupled to external communications circuitry, such 
as a modem 42 and a satellite decoder 44. Modem 42, and any additional modems 

25 as desired, may be of any suitable type, such as a 56kb/s modem in accordance with 

present technology, a cable modem, or any suitable external network 
communications interface. Decoder 44 may similarly be any suitable satellite or 
wireless interface, such as an ERD of the type available from Scientific Atlanta of the 
United States. As described more fully below, the use of parallel media for 

30 transmitting and receiving data permits the DCCS 40 to optimize the use of 

available bandwidth in data exchanges between the facility and the remote service 
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provider. By way of example, modem 42 may provide bandwidth of 56kb/s, while 
decoder 44 offers a considerably broader bandwidth, such as 500kb/s. 

The data communications to and from facility 12 are provided by an external 
5 network link 46 routed to modem 42, and by a satellite link 48 routed to decoder 44. 

External network link 46 is coupled, such as via conventional telephony cables, 
optical fibers, or otherwise, to a network 50, such as a wide area network. Network 
50 may be any suitable type of network, however, including virtual private 
networks, or the Internet. Isolation and protection of the integrity of the information 
10 system of facility 12 may be assured by one or more firewalls 52. Satellite link 48, 

which also generally forms part of the external network for communicating data to 
and from the facility, functions to receive data relayed via satellite 54, or through 
ground-based repeaters, transmitters, and so forth. 

15 Data from facility 12 is exchanged with a service provider 14 through the 

external network connections described above. In general, remote service provider 
14 may include a principle site 56, and additional cites 58, interconnected through 
open or proprietary networks. Remote service provider 14, by way of example, may 
include a facility or facilities for receiving data and service requests from the 

20 medical diagnostic facility on a subscription or contract basis. Services, data, 

training, technical assistance, and other information may then be provided to the 
subscribing facilities through the network connections and in accordance with the 
techniques described below. In the illustrated example, remote service provider 14 
includes its own internal network, such as an Ethernet-based local area network. 

25 

A series of clients or systems are interconnected via the network for 
exchanging data both internally and with the medical diagnostic facility. By way of 
example, a service system, designated generally by reference numeral 62, is 
provided for receiving and processing service data, such as service requests, protocol 
30 requests, questions, and so forth. Service system 62 may also be equipped for 

scheduling regular or special service calls, providing reports and analysis of 
operational or parameter data, and so forth. In the illustrated example, remote 
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service provider 14 also includes an automated support center as represented 
generally at reference numeral 64. The center may perform a variety of automated 
functions, including the acquisition or collection of operational parameters and data 
from the facility as described below. In general, many or all of the functions 
5 performed by the ASC may be fully automated, requiring little or no operator 

intervention. Data collected in accordance with the routines executed by the ASC 
are stored and made available upon demand. Remote service provider 14 may also 
include various electronic commerce systems 66 designed to provide data, receive 
orders, process orders, and perform accounting and financial transactions upon 
10 request from the medical diagnostic facility. An educational unit or system 68 may 

further be provided for offering educational or training programs, providing manuals 
or documentation, and so forth. 

While certain of the systems of the remote service provider may be 
15 configured for direct link to one or more medical diagnostic facilities or diagnostic 

systems, in the illustrated example, they are configured for communication with the 
diagnostic systems over the internal network 60 and through a communications 
interface 70. Communications interface 70 will typically include a data router, and 
other hardware and software for appropriately addressing data received from the 
20 medical diagnostic facility to one or more of the internal systems of the remote 

service provider, and for directing communications from these systems to the 
medical diagnostic facility. Interface 70 communicates the data via one or more 
modems 72, and via a satellite transmitter 74. Where desired, further network or 
satellite links may be provided to specific systems of the remote service provider 
25 such as a transmitter 76 provided for the educational unit 68. Each of the 

communications devices is coupled to a data link, including a fresh data link 78 for 
modem 72, and satellite links 80 and 82 for transmitters 74 and 76, respectively. 
The data link 78 preferably protects the integrity of the network and data of remote 
service provider 14 via one or more firewalls 84 or similar protection devices. 



30 



The system topology illustrated in Fig. 1 permits data to be exchanged 
interactively between the medical facility and the remote service provider. As 
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discussed below, the data may be exchanged at the initiation of the medical 
diagnostic facility, or of systems within the facility, via DCCS 40. Alternatively, 
communications may be initiated by the remote service provider, such as to respond 
to data or service requests, to access or acquire data from the diagnostic systems 
5 through the DCCS, or to provide various services, including instructional materials, 
training sessions, and so forth, via the external network links. 



Fig. 2 illustrates an exemplary configuration for DCCS 40, including its 
associated peripheral devices and software suite. In the illustrated embodiment, 

10 DCCS 40 includes a central processing unit 86, which may comprise a 

commercially available microprocessor within a general purpose or application- 
specific computer. The CPU is coupled to a variety of hardware and functional 
circuitry to carry out the functions described herein. For example, as shown in Fig. 
2, the CPU is coupled to a communications interface 88 to transmit and receive data 

15 via the external network as described above, and to similarly transmit and receive 

data with the diagnostic systems via the internal network. Thus, communications 
interface 88 may coordinate communications through one or more modems 42 
coupled to the data link 46. The satellite decoder 44 similarly channels data through 
the DCCS via satellite link 48. An additional network interface 90, such as an 

20 Ethernet interface, permits the exchange of data via the internal network 20 of the 

facility. 



In addition to these communication components, DCCS 40 includes memory 
circuitry 92 and additional support components. Memory circuitry 92 may include 

25 any suitable memory, such as disc drives, random access memory, read-only 

memory, dynamic random access memory, optical storage, and so forth. Memory 
circuitry 92 stores both software routines executed by the DCCS, as well as data 
collected by the DCCS for transmission to the remote service provider, and data 
received from the remote service provider for distribution to designated or addressed 

30 diagnostic systems of the facility. A backup system 94 is preferably provided for 

periodically creating archive versions of selected files, routines, collected data, and 
so forth. One or more peripheral interfaces, as designated generally at reference 
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numeral 96, is provided for receiving input signals from an operator interface, and 
for displaying data and outputting data as desired. In the illustrated embodiment, 
such peripheral devices include a computer monitor 98 and printer 100 as output 
peripherals. Input peripherals may include a conventional keyboard 102, mouse 
5 104, and any other suitable input peripheral devices. 

While certain software applications and utilities may be stored and executed 
on various clients of the facility, particularly within the imaging systems, the RIS, 
the HIS, and the PACS, DCCS 40 preferably independently executes a variety of 

10 applications to perform the data communications functions assigned to it. These 

applications, designated generally by reference numeral 106 in Fig. 2, are preferably 
stored in memory circuitry 92, and executed by CPU 86. Alternatively, certain of 
the applications may be resident elsewhere, and completely or partially executed by 
other data processing circuitry. The applications 106 will generally include a variety 

15 of commercially available application routines, and may further include customized 

routines executed by the CPU. A software suite 108 is therefore available for 
execution by the CPU, both automatically, on a regularly scheduled basis, or in 
response to operator prompts or prompts from the remote service provider. 

20 Application routines, designated generally by reference numeral 110 in Fig. 

2, may include software for collecting data from the diagnostic systems, storing such 
data, transmitting data to the remote service provider, and routing data from the 
service provider to designated systems. In the embodiment illustrated in Fig. 2, 
software suite 108 includes database software for associating collected data from the 

25 diagnostic systems in a relational manner. Such data preferably includes the 

identification of the systems, their locations, utilization data, as well as a variety of 
parameter data useful in determining the operational state of the system and the 
possible need for service. As will be appreciated by those skilled in the art, in the 
case of diagnostic imaging systems, a wide variety of operational or parameter data 

30 may be stored directly at the individual diagnostic systems and may provide 

extremely useful indications of the performance of the systems, and possible future 
service needs. 
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Software suite 108 preferably also includes server software, such as 
Windows NT server software from Microsoft Corporation of Redmond, 
Washington, as well as web server software. The server software permits the DCCS 
5 to function as a server, both for the internal clients and for external clients or users. 

Browser software is also preferably included, permitting an operator, through the 
operator interface devices of the DCCS, to log on to sites, such as on the Internet to 
request information and data, transmit service and data requests, and so forth. In the 
preferred embodiment, the browser software may also function on the DCCS to 
10 permit interactive interfacing directly at one or more of the diagnostic systems, 
particularly the diagnostic imaging systems. Routing software is also functional on 
the DCCS to permit data packets received from the remote service provider to be 
appropriately transmitted to designated diagnostic systems within the facility via the 
internal network. 

15 

Additional applications of software routines are also preferably included on 
the DCCS, including diagnostic and service routines, and interactive service 
routines. These routines, which may include an interactive service platform, permit 
service requests to be generated, preferably via a web browser interface for 

20 immediate of delayed transmission to the remote service provider. These 

applications also preferably permit the receipt of reports and service data back from 
the remote service provider in an interactive fashion. Reporting software on the 
DCCS permits reports to be generated, particularly reports relating to 
communications activities logged as described below. Security routines may be 

25 executed as part of the software suite, preferably to verify the integrity of data 

transmitted and received via the DCCS, and to limit access both to the internal 
network from outside users, including the remote service provider, and access to 
remote websites or providers from the clients coupled to the internal network. 

30 Asset management applications preferably also run on the DCCS to enable 

various business, financial, and management functions to be performed, preferably 
in coordination with similar functions performed by the RIS and HIS. In the 
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illustrated embodiment, for example, transactional and accounting routines may be 
operational, such as to maintain an accounting for remote services utilized by the 
facility, any charges or fees associated with such services, similar accounting for any 
electronic commerce transactions performed, and so forth. An asset tracking routine 
5 may provide for analysis of locations and availability of specific clients or assets, 

particularly of mobile clients which may be traced through the internal network to 
specific locations. 

The components of the software suite illustrated in Fig. 2 and discussed 
10 above, may include various commercially available applications software packages, 

or software which is created specifically for the facility or application, hi general, 
however, any application-specific software may be readily developed by those 
skilled in the art, without undue experimentation. In the presently preferred 
embodiment, commercially available software applications included in the system 
15 and executed by the DCCS include database software available from Oracle 

Corporation of Redwood City, California, multimedia software available from 
Eloquent Systems, Inc. of North Vancouver, British Columbia, web server software, 
such as Netscape Enterprise software available from Netscape Communications of 
Mountain View, California, and browser software, such as software available from 
20 Microsoft Corporation of Redmond, Washington, or Netscape Communications. 

Fig. 3 illustrates general flow of data within the overall system topology 
illustrated in Fig. 1. As shown in Fig. 3, two-way data flow is provided between the 
DCCS 40 and the various clients 24, and other networked systems, such as the RIS 

25 34, the HIS 36, and the PACS 38. As noted above, clients 24 preferably include 

medical diagnostic imaging systems which are linked to the remote service provider 
through the DCCS for interactive data and service needs. DCCS 40 also 
communicates data to and from memory circuit 92, which in the diagram of Fig. 3 
may include databases, both local to the DCCS and at various networked nodes of 

30 the facility. 
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Within remote service provider 14, data may be exchanged between 
interface 70 and the various systems and subsystems, such as those described above, 
as service system 62, ACS 64, electronic commerce systems 66, and educational 
units or systems 68. Each of these systems may include other networked systems or 
5 stations, such as work stations 112 which, through the service system 62 permit 

applications engineers to access diagnostic system data, address specific service 
needs and requests, and so forth. One or more databases 1 14 and 1 16 are preferably 
linked to the systems of the remote service provider to permit parameter and 
operational data to be stored relationally, and retrieved as desired for analysis, 
10 reporting, invoicing, and so forth. It should be noted that the components of the 

2 remote service provider, including the systems illustrated in Fig. 3, may exchange 

j! data either locally or through a wide variety of network configurations, including 

O configurations permitting one or more of the systems and databases to be located in 

J geographically distant locations from one another. 

4* 15 

H The data exchanged internally within the medical diagnostic facility and the 

?§§ 

J|J remote service provider are then exchanged via the external network links between 

rU these facilities. In the illustrated embodiment, these network links include the 

yg satellite links 48 and 80, routing data through a satellite 54 or land-based circuitry, 

20 as well as a wide area network as defined by links 46 and 78, and network 50. 

The data communications technique and components described above permit 
access to and exchange of data in accordance with a variety of routines. Logical 
steps in certain of these routines are illustrated in Figs. 4-9. 

25 

Referring to Fig. 4, a first routine permits service and data requests to be 
formulated at the diagnostic facility for transmission to the remote service provider. 
The service request routine, designated generally by reference numeral 200, begins 
at step 202 where a client of the facility generates a data request. In the present 
30 context, such data requests may include a wide range of service, data, software, and 

similar requests. Specifically, for medical diagnostic imaging systems, these 
requests may include descriptions of specific problems occurring at the system, 
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requests for imaging protocols for software, operational inquiries, and so forth. 
However, similar requests may originate in networked clients, such as internal 
training services of the facility, such as for multimedia training materials which may 
be transmitted through the DCCS as described below. It should also be noted that 
the data request may be formulated at diagnostic systems which include software 
running locally for the request formulation, or through applications running on the 
DCCS and accessible through the diagnostic system. At step 204, these requests are 
transmitted to the DCCS. At step 206, the requests are screened and any license 
verification may be performed, such as to determine whether the requesting 
diagnostic system is currently licensed for the type of request made. 

As indicated at step 208 in Fig. 4, service or data requests may be generated 
directly at the DCCS 40. Such requests may be formulated through the operator 
interface components of the DCCS, preferably through an interactive interface, such 
as a web browser or other graphical user interface. It should be noted that the ability 
to generate data and service requests directly at the DCCS offers significant 
advantages over existing techniques for interactive service of diagnostic systems. 
For example, where the installed base of equipment in a medical facility is not or 
cannot be equipped for direct communication via an external network, the 
equipment can nevertheless be coupled to the DCCS via the internal network. 
Moreover, many medical diagnostic systems and devices are not equipped for 
operator interface so as to permit formulation of service and data requests. 
However, the ability to generate such requests directly at the DCCS allows such 
systems to be included in an overall service provision scheme. Following 
generation of the request at step 208, the screening and license verification functions 
of step 206 may be performed as indicated in Fig. 4. 

At step 210 in Fig. 4, the data included in the request is parsed, such as to 
identify the requesting or designated diagnostic system, specific problems or issues 
to be addressed, an operator or clinician formulating the request, and so forth. At 
step 212, this information is logged in the memory circuitry of the DCCS. At step 
214 the request is placed in a cue for transmission to the remote service provider. 
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Where a connection session is currently taking place, the request may be transmitted 
at the earliest communications window available, as indicated at step 216. Where 
necessary, transmission at step 216 may require the initiation of a connection 
session. In the presently preferred embodiment, such connections may be initiated 
5 either by the DCCS, or by the remote service provider. Where desired, receipt and 

transmission of the request is confirmed back to the designated diagnostic system as 
indicated at step 218. Moreover, where additional client data is necessary to address 
the request, this data may be retrieved as indicated at step 220. Such data may 
include particular configurations or parameter settings which may have been in place 
10 during an imaging sequence, for example, data streams produced by an imaging 

system or monitor, service history data, and so forth. 

The requests formulated in accordance with the logic of Fig. 4 are 
transmitted via the external network to the remote service provider. Fig. 5 illustrates 

15 exemplary logical steps in handling such requests. The handling procedure, 

indicated generally by reference numeral 250, begins with receipt of the request at 
step 252. At step 254 an acknowledgment message may be formulated by the 
remote service provider, such as through an automatic return messaging routine, and 
sent back to the DCCS for informing the facility that the request has been received 

20 and is being handled. Such acknowledgement may include additional details 

regarding the handling, such as reference numbers, dispatch numbers, handling 
schedules, and so forth. At step 256, data from the request is parsed for logging by 
the remote service provider. The parsing performed at step 256 may include parsing 
for similar data to that reviewed at step 210 of Fig. 4, such as for an identification of 

25 the requesting or designated system, identification of the facility, service 

subscription data, and parameter or operational data necessary for reviewing and 
addressing the request. At step 254, license or accounting records stored within a 
database of the remote service provider are accessed and updated to make note of the 
request. Depending upon the desired accounting structure, the request may be 

30 handled under an existing contract or subscription, on a warranty basis, on a pay- 

per-use basis, or otherwise. 
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As noted above, depending upon the type of request transmitted from thee 
medical diagnostic facility, its handling by the remote service provider may assume ] 
various modes. As indicated at step 260 of Fig. 5, the request is addressed within 
the service provider for handling, such as for automatic handling, or for intervention 
of a service engineer. In either event, it may be necessary to obtain additional data 
from the system to properly address the service request. In the case of medical 
diagnostic imaging equipment, such additional information may include raw or i. 
processed image data files, system configuration parameters and settings, and so :j 
forth. As indicated at step 262, such data may be retrieved through the external 
network, DCCS, and internal network of the facility. Once sufficient information t 
has been accessed to address the request, the requested data, reports, analysis, and so 
forth may be then transmitted from the remote service provider back to the ^ 
designated medical diagnostic system through the DCCS, or directly back to the ; 
DCCS where the request originated there. The transmissions at step 264 may 
include a wide range of data. For example, the data may include configuration 
parameters, suggested troubleshooting steps, electronic messages, electronic 
documentation, software upgrades, protocols, and so forth. Where necessary, a field j 
service engineer may be dispatched, as indicated at step 266 in Fig. 5 for additional 
follow up. The field service engineer dispatched at step 266 may address the request | 
either in person or remotely, such as through telephone or other connections from 
the remote service provider. 

As noted above, responses to requests from the medical diagnostic facility 
may be transmitted through alternative media, such as a wide area netwoik and a 
25 satellite link. The logic of Fig. 5 illustrates one embodiment for processing such 

transmissions in response to requests. While various media may be employed for 
this purpose, in a presently preferred embodiment the media have significantly 
different transmission rates or bandwidths, enabling certain types of transmissions to I 
be made through a first type of connection, such as the wide area network, with 
30 more demanding or specific transmissions being made through a higher bandwidth 

medium. Various approaches may be adopted for deciding which of the media will 
be employed for the transmission. For example, the remote service provider may 
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manually or automatically select a media depending upon the requirements or 
preferences of the medical diagnostic facility. Moreover, specific types of 
transmissions may be made over one medium or the other, such as streaming media 
transmissions which may require substantial bandwidth, may occupy a link for 
5 substantial periods of time, or may be particularly susceptible to interruption or 

network delays. 

In the presently preferred embodiment, the selection of the wide area 
network or the satellite link is made based upon a category of data or transmission. 
Thus, at step 268 of Fig. 5, the category is reviewed and one of the available media 
is selected. By way of example, multi-media presentations, training sessions, and 
similar data categories are transmitted through the satellite link, while more 
conventional data transmissions are made through the wide area network. 
Depending upon the transmission category, then, the medium is selected as indicated 
at either step 270 or 276. The transmission is then scheduled as indicated at step 272 
or step 278. In the case of training sessions, for example, the transmission may be 
scheduled for a later date and time, with the designated diagnostic system being a 
specific location, training room, or other client of the diagnostic facility. Finally, as 
indicated at either step 274 or 280, the scheduled transmission is made through the 
selected medium. 

Fig. 6 indicates exemplary control logic for receiving and processing 
transmissions back from the remote service provider to the diagnostic facility. This 
control logic, designated generally by reference numeral 300, begins with receipt of 
25 the data transmission at step 302. This receipt is through the DCCS, such as in an 

ongoing data transmission session. At step 304, the data received is parsed to 
identify at least the designated or addressed diagnostic system. At step 306 the data 
is forwarded from the DCCS to the designated system via the internal network of the 
facility. It should be noted that step 306 may include storing all or part of the data, 
30 or information derived or parsed from the data in the memory circuitry of the DCCS, 

or in another database of the facility. At step 308 the receipt and communications 
exchange is logged by the DCCS. 
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Where required, alternative procedures for the receipt and processing of data 
may be implemented as indicated in Fig. 7. The alternative receipt steps indicated 
generally by reference numeral 350, may be desirable, for example, in the receipt of 
5 digital data via satellite links, with the data being routed through the DCCS for 

distribution. In particular, such satellite communications systems, or other 
alternative media, may not require two-way communication. Accordingly, certain 
of the information for addressing the data may be transmitted in parallel through the 
other medium, particularly through a wide area network. Thus, at step 352, a 

1 0 handshake routine is executed between the DCCS and the remote service provider to 

insure appropriate connectivity and the ability to exchange the necessary 
information. At step 354, an authentication procedure may be performed to insure 
that the transmission session via the parallel medium conforms to the request and to 
the transmission schedule. At step 356, the recipient address is identified and 

15 confirm, such as to insure that the transmission channel is appropriately tuned or 

selected, and that the client or diagnostic system is identified within the facility. At 
step 358, the transmission is received and demodulated, filtered, or otherwise 
processed. As indicated at step 360, the data received via the parallel medium may 
require additional processing, such as to packetize the data for transmission over the 

20 internal network. Following such processing, the data is distributed to the 

designated system. The communication sequence and transmission is logged as 
indicated at step 362. 

In addition to the interactive exchange of service and other data, the present 
25 technique permits the acquisition of operational and parameter data from the medical 
diagnostic systems which are clients of the internal network of the facility via a 
streamlined procedure. Fig. 8 illustrates exemplary steps in this procedure, through 
control logic designated generally by reference numeral 400. In general, the 
procedure enables the data to be acquired or collected from the networked diagnostic 
30 systems through the DCCS, and transmitted from the DCCS to the remote service 

provider. In heretofore known approaches to providing service to medical 
diagnostic systems, such data was typically acquired through direct connection to a 
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desired diagnostic system, requiring a large number of connections to be made 
independently and placing substantial demands on infrastructure, both within the 
facility and at the remote service provider. Moreover, where diagnostic systems 
were not equipped for connectivity directly to the remote service provider, little or 
5 no information could be obtained, particularly directly from the system. 

In the present approach, information may be obtained through several 
different processes, initiated both automatically and manually. In the exemplary 
logic of Fig. 8, the data acquisition process may begin with initiation of an automatic 

10 polling routine at step 402. This routine would be executed by the DCCS which 

contacts each networked system, or designated systems from which data is desired, 
on a preestablished schedule. By way of example, the schedule may include 
periodic data acquisition throughout a 24 hour period, or less frequent acquisition. 
Depending upon the routine and schedule, the clients are contacted at step 404 of 

15 Fig. 8. At step 406 the data is accessed, such as by retrieval from memory circuitry 

of the client diagnostic systems. At step 408 the data may be filtered, such as to 
determine whether complete or incomplete information is acquired, to parse data 
which is not desired, such as patient-specific data, and so forth. At step 410, the data 
is recorded, such as in the memory circuitry of the DCCS. 

20 

As an alternative to the polling process described above, certain data may be 
collected upon occurrence of a specific event in the diagnostic system or within the 
facility. For example, where certain of the systems of the facility are mobile, 
connection of the mobile system to the internal network may cause the DCCS to 

25 execute the data acquisition routine for the newly-connected system. Thus, as 

indicated at step 412 of Fig. 8, the specific system or asset may change a state, such 
as establishing or renewing a connection to the internal network. At step 414, then, 
the system is accessed and desired information is transferred from the system to the 
DCCS. By way of example, to permit asset tracking, asset management, 

30 productivity analysis, and other functions, the location of mobile assets may 

identified and recorded for later use, or to permit the facility personnel to track the 
assets. 
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The data acquisition sequences may also be initiated by a manual request, as 
indicated at step 416 in Fig. 8. The manual request may be input via the operator 
interface components of the DCCS, such as to access and display performance, 
5 utilization, and other characteristics or parameters of the networked systems. In 

response to the manual request, the designated system is accessed, as indicated at 
step 418, and the desired data is located and transmitted from the device memory as 
indicated at step 420. 

10 To facilitate transmission of acquired data to the remote service provider, the 

acquired data is preferably stored locally at the diagnostic facility, and transmitted to 
the remote service provider in one or more data communication sessions. Such 
sessions may be scheduled for convenient times, such as during off-peak hours, 
nighttime hours, weekends, and so forth. Fig. 9 illustrates steps in exemplary 

15 control logic, designated generally by reference numeral 450, for transmitting the 

data once acquired at the facility. 

Referring to Fig. 9, the data transfer is first scheduled as indicated at step 
452. As noted, this schedule may be established for convenient times, both for the 

20 diagnostic facility and for the remote service provider. It should be noted, however, 

that such data transfers may be initiated by operator intervention, where desired. As 
indicated at step 454, a connection is then established between the diagnostic facility 
and the remote service provider. The connection may be initiated by either the 
facility or the remote service provider, the remote service provider being the 

25 preferred initiator in the present embodiment. Also, at step 454, the remote service 

provider prompts the transfer of the data, such as through a communications routine 
stored at both the DCCS and the remote service provider. In response to the prompt, 
the data is accessed from the medical facility memory or data repository and 
transferred to the remote service provider as indicated at step 456. During or 

30 following the transfer, any desired parsing, filtering, and other processing are 

performed as indicated at step 458. In particular, the transferred data is preferably 
parsed to identify the individual diagnostic systems originating the data, and to 
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separate operational and parameter data for the individual systems from one another. 
The data is then stored, preferably in relational databases, for later retrieval and 
analysis. Finally, at step 460, the data transfer session is logged, preferably both at 
the diagnostic facility and at the remote service provider. 

While the invention may be susceptible to various modifications and 
alternative forms, specific embodiments have been shown by way of example in 
the drawings and have been described in detail herein. However, it should be 
understood that the invention is not intended to be limited to the particular forms 
disclosed. Rather, the invention is to cover all modifications, equivalents, and 
alternatives falling within the spirit and scope of the invention as defined by the 
following appended claims. 
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CLAIMS: 

1. A medical facility data communications system, the system 
comprising: 

an internal data communications network; 
5 a plurality of clients coupled to the internal network and uniquely addressed 

on the internal network; and 

a data communications control system coupled to the internal network for 
receiving client data from the clients, transmitting client data to a remote service 
provider, receiving addressed data from the remote service provider, and distributing 
1 0 the addressed data to the clients. 

2. The system of claim 1, wherein the internal data communications 
network includes at least one local area network. 

15 3. The system of claim 2, wherein the internal data communications 

network includes a high speed Ethernet network. 

4. The system of claim 1, wherein the clients include at least one 
medical imaging system configured to produce image data. 

20 

5. The system of claim 4, wherein the at least one imaging system is 
selected from a group including medical resonance imaging system, computed 
tomography systems, ultrasound systems, and x-ray systems. 

25 6. The system of claim 1, wherein the clients include a hospital 

information system. 

7. The system of claim 1, wherein the clients include a radiology 
department information system. 

30 

8. The system of claim 1, wherein the clients include a picture 
archiving and communication system. 
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9. The system of claim 1, wherein the data communications control 
system is configured to access data from networked clients in accordance with a 
predetermined data acquisition routine. 

10. The system of claim 9, wherein the data accessed includes 
operational parameters of the clients. 



11. The system of claim 9, wherein at least one of the clients is a mobile 
1 0 client, and wherein the data accessed includes location of at least the mobile client. 



12. The system of claim 11, wherein the location of the at least one 
mobile client is accessed in response to connection of the at least one mobile client 
to the internal network. 

15 

13. The system of claim 1, wherein the data communications control 
system includes an operator interface, and wherein the system is configured to 
access data from networked clients in response to an operator request input via the 
operator interface. 

20 

14. The system of claim 1, further comprising an external network 
interface for exchanging client data and addressed data between the data 
communications control system and the remote service provider. 

25 15. The system of claim 14, wherein the external network interface 

includes an interface for at least two different data communications media. 



16. The system of claim 1, wherein all data communications between 
selected clients and the remote service provider are routed through the data 
30 communications control system. 
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17. A data communications system for a medical diagnostic facility, the 

system comprising: 

a plurality of clients linked to an internal network, the clients including a 
medical diagnostic imaging system; 

a data communications control system linked to the internal network for 
receiving client data from the clients, distributing addressed data to the clients, 
transmitting client data to a remote service provider and receiving addressed data 
from the remote service provider; and 

an external network interface coupled to the data communications control 
system for transmitting the client data to the remote service provider and for 
receiving the addressed data from the remote service provider. 

18. The system of claim 17, wherein the client data includes operational 
data for evaluating performance of the medical diagnostic imaging system. 

19. The system of claim 17, wherein the internal network is a local area 
network and the external network is a wide area network. 

20. The system of claim 19, wherein the internal network is an Ethernet 
network. 

21 . The system of claim 19, wherein the wide area network includes the 
Internet. 

22. The system of claim 17, wherein the clients include a hospital 
information system. 

23. The system of claim 17, wherein the clients include a radiology 
department information system. 

24. The system of claim 17, wherein the clients include a picture 
archiving and communication system. 
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25. The system of claim 17, wherein the data communications control 
system is configured to access data from networked clients in accordance with a 
predetermined data acquisition routine. 

26. The system of claim 25, wherein the data accessed includes 
operational parameters of the clients. 

27. The system of claim 25, wherein at least one of the clients is a 
mobile client, and wherein the data accessed includes location of at least the mobile 
client. 

28. The system of claim 27, wherein the location of the at least one 
mobile client is accessed in response to connection of the at least one mobile client 
to the internal network. 

29. The system of claim 17, wherein the data communications control 
system includes an operator interface, and wherein the system is configured to 
access data from networked clients in response to an operator request input via the 
operator interface. 

30. The system of claim 17, wherein the data communications control 
system is configured to store and execute communications interface routines 
interactively with the clients. 

25 

31. The system of claim 30, wherein the communications interface 
routines include a web browser routine. 

32. A communications system for a medical diagnostic facility, the 
30 system comprising: 

an internal network; 
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a plurality of clients configured for connection to the network for 
transmission of client data and for receipt of addressed data, the clients including a 
physically mobile client; and 

a data communication control system coupled to the internal network and to 
5 an external network for communicating client data and addressed data between the 

clients and a remote service provider, the data communications control system being 
configured to automatically access client data including data indicative of a location 
of the mobile client. 

10 33. The system of claim 32, wherein the control system is configured to 

detect the location of the mobile client upon connection of the mobile client to the 
network. 

34. The system of claim 32, wherein the clients include a medical 
15 diagnostic imaging system, and wherein the client data includes operational data for 

evaluating performance of the medical diagnostic imaging system. 

35. The system of claim 32, wherein the internal network is a local area 
network and the external network is a wide area network. 

20 

36. The system of claim 32, wherein the internal network is an Ethernet 
network. 

37. The system of claim 36, wherein the wide area network includes the 
25 Internet. 

38. The system of claim 32, wherein the clients include a hospital 
information system. 

30 39. The system of claim 32, wherein the clients include a radiology 

department information system. 
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40. The system of claim 32, wherein the clients include a picture 
archiving and communication system. 

41. The system of claim 32, wherein the data communications control 
5 system is configured to access data from networked clients in accordance with a 

predetermined data acquisition routine. 

42. The system of claim 41, wherein the data accessed includes 
operational parameters of the clients. 

10 

43. The system of claim 32, wherein the data communications control 
system includes an operator interface, and wherein the system is configured to 
access data from networked clients in response to an operator request input via the 
operator interface. 

15 

44. The system of claim 32, wherein the data communications control 
system is configured to store and execute communications interface routines 
interactively with the clients. 

20 45. The system of claim 32, wherein the communications interface 

routines include a web browser routine. 

46. A method for communicating data in a medical diagnostic facility, 
the method comprising the steps of: 
25 (a) transmitting client data from a plurality of networked clients to a data 

communications control system via an internal network; 

(b) processing the client data in the data communications control system; 

(c) transmitting at least a portion of the client data from the data 
communications control system to a remote service provider via an external 

30 network. 
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47. The method of claim 46, comprising the further steps of receiving 
addressed data from the remote service provider via the data communications 
control system, and distributing the addressed data to an intended client via the 
internal network. 

48. The method of claim 46, wherein the client data is transmitted to the 
data communications control system in response to a request from the control 
system. 

49. The method of claim 48, wherein the control system includes an 
operator interface, and wherein the request is generated via the operator interface. 

50. The method of claim 46, wherein the client data is transmitted to the 

cojitrol system in a transmission created by operator intervention at the client. 

\ 

51. The method of claim 50, wherein the transmission is created via an 
interface routine executed interactively by the control system and client. 

52. The method of claim 5 1 , wherein the interface routine includes a web 
browser application. 

53. The method of claim 46, including the step of storing client data for 
access by the control system. 

54. The method of claim 46, including the step of logging 
communications between the clients and the control system. 

55. A method for managing data communications in a medical 
diagnostic facility, the method comprising the steps of: 

(a) coupling a plurality of clients to an internal network, the clients 
including at least one physically mobile client; 
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(b) transmitting client data from the clients to a data communications 
control system, the client data including at least data indicative of a location of the at 
least one mobile client; and 

(c) storing the client data. 

56. The method of claim 55, wherein the client data indicative of the 
location of the at least one mobile client is transmitted upon connection of the at 
least one mobile client to the network. 

57. The method of claim 55, comprising the further step of accessing 
client data representative of performance of the clients. 

58. The method of claim 55, wherein the control system includes an 
operator interface, and wherein client data is accessed via the internal network in 
response to operator intervention via the interface. 

59. The method of claim 55, comprising the further step of transmitting 
at least a portion of the client data to a remote service provider via an external 
network. 

60. The method of claim 55, comprising the further steps of receiving 
addressed data at the control system via an external network, and distributing the 
addressed data to an intended client. 
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ABSTRACT OF THE DISCLOSURE 

A technique for exchanging data between networked medical diagnostic 
systems of a medical institution is provided. The diagnostic systems may include 
imaging systems, data management systems, monitors, and so forth, connected to 
an internal network of the institution. A data communications control system is 
connected to the internal network and receives data from the systems, transmits 
data to a remote service provider via an external network, and routes data received 
through the external network back to the diagnostic systems. 
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